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(57) A data processing method for efficiently trans- 
porting multimedia data packets of fixed and/or variable 
length over an Assynchronous Transfer Mode (ATM) 
network made to transport fixed length ATM cells includ- 
ing a fixed length user data payload and a fixed length 
ATM header. 

Said data processing method includes concatenat- 
ing said fixed and/or variable length user data and 
appending said concatenated data with a so-called 
trailer defining the various concatenated user data 
lengths and identifications, for being further split into 
ATM cells payloads before being transmitted over said 
ATM network. 
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This invention deals with digital networks and more 
particularly with a data processing method for efficiently 
transporting fixed or variable length multimedia data 5 
packets over packet switching networks. 

Background of the Invention 

The telecommunications carrier industry began to ig 
develop a concept called "Broadband Integrated Serv- 
ices Digital Network" or B-ISDN. This was conceived as 
a carrier service to provide high speed communications 
to end users in an integrated way. 

Different techniques have been developed for trans- is 
porting information over a network, such as packet 
switching techniques whereby the digitized data are 
arranged into so-called bit packets, and circuit switching 
techniques. In packet switching, the bit packets may 
either be of fixed length (like in the so-called Asynchro- 20. 
nous Transfer Mode (ATM) where the packets, also 
called cells, are all of a conventional fixed length), or be 
variable length. 

The basic advantage of packet switching tech- 
niques over circuit switching techniques, is to allow a 25 
statistical multiplexing of different types of data over a 
link, which optimizes the transmission bandwidth. The 
present invention shall try to keep this advantage under 
various circumstances. Although the present invention 
applies to all kinds of packet switching techniques, 30 
including Frame Relay, the technology selected here as 
an example made to illustrate the invention and show 
how to deliver the B-ISDN service, in the detailed imple- 
mentation, is the "Asynchronous Transfer Mode" or 
ATM. 35 

The almost universal acceptance of ATM comes 
from the fact that ATM is a compromise. ATM does han- 
dle all the different kinds of communication traffic, 
including voice, data, image, video, high quality sound 
and many others, and it can be used in both the LAN 40 
(Local Area Network) and the WAN (Wide Area Net- 
work) network environments. 

ATM does not handle voice as efficiently as does an 
isochronous network, it does not ether handle video as 
easily as isochronous transfer does, it may not always 45 
handle data as effectively or efficiently as a Packet 
Transfer Mode or Frame Relay system do. and it is likely 
to be problematic in any high error rate environment, but 
it however offers a tremendous advantage over other 
networks since it enables combining all these kind of so 
multimedia data for transport over the same network. 
This means that instead of having a proliferation of 
many specialized kinds of equipment for different func- 
tions we can have a single type of equipment and net- 
work which will do everything. 55 

The basic key concepts of ATM are as follows : 

All informations (voice, image, video, data ...) are 
transported through the network in very short, fixed 
length (48 data bytes plus a 5 byte header) blocks called 
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"cells", (herein also r to as ATM cells). 

The information flow" along paths, called "virtual 
channels" (VC) set up as a series of pointers through 
the network. The cell header contains an identifier that 
links the cell to the correct path towards its destination. 
Cells on a particular virtual channel always follow the 
same path through the network and are delivered to the 
destination in the same order in which they are 
received. 

ATM is designated so that simple hardware based 
logic elements may be employed at each node to per- 
form the switching. On a link of 1 Gbps a new cell 
arrives and a cell is transmitted every 0.43 microsec. 
This leaves little time to decide what to do with an arriv- 
ing cell. 

At the edges of the network, i.e. on a network port 
or an access node, user data frames or packets are bro- 
ken up into cells. Continuous data streams such as, for 
instance, voice and video are assembled into ATM cells. 
At the destination side of the network, the user data 
frames are reconstructed from the received cells and 
forwarded to the end user in the form that they were 
delivered to the network This adaptation function is 
considered part of the network but is in a higher layer 
function, which is called ATM Adaptation Layer (AAL). 
These edge or port equipments are already operative 
and well defined by International Standards perfectly 
specifying, for instance, so-called ATM Adaptation Lay- 
ers (AALs). 

The ATM cell switching network only checks cell 
headers for errors and simply discards cells in error. 
The adaptation function AAL is external to the switching 
network and depends somewhat on the type of traffic, 
but for data traffic it usually checks for errors in data 
frames received and in case of error found, then it dis- 
cards the whole frame. At no time does the ATM net- 
work attempt to recover from errors by the re- 
transmission of information. This function is up to the 
end user devices and depends on the type of traffic 
being carried and the adaptation layer being used. For 
instance, end user equipments have been specified for 
recovering discarded voice data through so-called inter- 
polation/ extrapolation techniques. 

Information about ATM networks can be found for 
example in "High Speed Networking Technology: An 
Introductory Survey". June 1993, Document Number 
GG24-3816-01, IBM International Technical Support 
Center, Raleigh. 

Information on the Standards of ATM can be found 
in the International Telecommunication Union (ITU) 
Recommendations. 

But, as mentionned above,' Asynchronous Transfer 
Mode (ATM) may be considered as lacking efficiency on 
a number of situations. For instance, when applying to 
voice transportation, whereby a Private Branch 
Exchange (PBX) serving a number of telephone sets is 
attached to a Voice Server which both codes and com- 
presses the digitized user's voices. In this case. 160 
bytes long data frames (or packets) may be compressed 
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by a factor 5 when applied to C^P**"™ fj^? 
fGSM) telephony, or even be compressed by a factor ». 
Accordmgly the data packets to be transported over 
Ss (a 48 data bytes long payload ♦ a 5 bytes £ng 
header) shall bear 32 bytes or 20 bytes payload data_ 
Therefore, one data packet provided to the ATM network 
port would not fill-up an ATM cell payload field. 

In other words either one pads each ATM cell with 
dummy bytes (say 1 6 or 28 bytes per ceil) or one aggre- 
gates user s frames into several consecufve ATM cell* 
S B one should note that the so-called byte .s referred 
to as "octet" in the International Telecommun.cat.on 
Union standards terminology). From an 
standpoint, the first solution should obv.ously be 
avoided as it leads to inefficient bandwidth occupancy. 
This leaves us with the second solution. 
One may easily imagine the various P^lems 
raised for handling in a conventional ATM networ : such 
multiple frames (or packets), particularly when they are 
of variable length like those issuing from a vok* s«ve 
performing silence removal operations, and/or shorter 
fhan a conventional ATM cell payload. be they proved 
to the ATM network directly or through another ^network 
e g a Packet Switching Access Network). On the other 
hand, one should bear in mind that Standards require- 
ments on ATM Adapter Layer (AAL) may then have to 
be redefined that enable performing the adequate 
encapsulation and transport of user data i pack ets be 
they fixed or variable length, onto an ATM cell stream. 
Accordingly, some of the existing networks hardware 
become useless, which, obviouly raises a number of 
serious problems from a practical standpo.nl 

The current International Telecommun.cat.on Union 
(ITU) standards do not specifically address the problem 
of aggregating composite short packets which could be 
of variable length, within an ATM cell in such a manner 
that the ATM Adaptation Layer at the receiving ^nd of 
the network can easily retreive the individual packets 
from the incoming ATM cell stream. 

Various solutions have been proposed that ecom 
mend creating a new standardized AAL *usintply.ng [in 
addition to the hassle of modifying the standards, also 
modifying the currently used hardware. 
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minimum delay. 

A further ob]H^>f this invention is to minimize 
delays and optimize the bandwidth exploitation by ena- 
bling to vehiculate user data packets by using e.ther so- 
called blocking techniques or so-called multiplexing 
techniques, or both, on the same network. 

Still another object of the invention is to provide a 
method for efficiently transporting fixed or variable 
.ength data packets over an ATM network based on 
applying the standardized ATM Adapter Layer typeS 
(AAL5) and therefore fitting to currently ex.st.ng ATM 
network hardware. . . 

These and other objects, character.st.es and 
advantages of this invention will become appa rent from 
a consideration of the following detailed descr.pt.on 
given with reference to the accompanying f igures. which 
specify and show a preferred embodiment of the inven- 
tion. 

20 Summary of the Invention 

This invention provides a data processing method 
for efficiently transporting multimedia packets of fixed 
and/or variable length over a digital packel ^swrtching 
network made to vehiculate f ixed length packets. said 
2£ including, on the transmit side, concatenating 
Sd multimedia data packets, issued from one or sev- 
eral users and appending said concatenated data 
Palets with a subheader or trailer whitf .trailer con- 
catenates User Channel Identifications (CIDs) and User 
Data Length(s) (UOLs) values of the respective con- 
SeUS !d£ packets, whereby a global payload is 
defined, for being transported over the network. 
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35 Brief Description of the Drawings 
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Objects of the Invention 

One object of this invention is to provide a data 
processing method for efficiently transporting fixed or 
variable length multimedia data packets over a d.g.tal 
packet switching network. 

Another object of this invention .s to prov.de a da a 
processing method for transporting fixed or variable 
length data packets, provided ether directly or through 
so-called Access Networks, over an ATM network, by 
efficiently feeding said data packets into conventual 

ATM cells. .. o 

Another object of this invention .s to prov.de a da a 
processing method for transporting fixed or var.ab e 
fenlth da?a packets into conventional ATM cells with 



Figure 1 represents an ATM network wherein.the 
invention could be implemented. 

Figure 2 is a presentation of the layer structure o 
the ATM Adapter layer 5 as defined in Jha >*™*%* 
Telecommunications Union (ITU) Standards appl.ed by 

Rg^S is the CPCS-PDU format for the AAL Type 

45 5 Figure 4 is a schematic representation of the inven- 
tion method as applied in accordance with the Stand- 
• ards (Functional model for the AAL type 5). 

Figure 5 is a schematic representation of the format 
of the CPCS layer payload in accordance with the .nven- 

50 ti00 ' Figure 6 (including Fig.SA and 6B) and Figure 7 are 
flowcharts for implementing the invention on the trans- 
mit side of an ATM network. 

Figure 8 is a representation of the International TW- 
55 ecommunications Standard Functional Mode for the 
AAL tvoe 5 on the receiver's side. 

Figure 9 is a flowchart for implementing the inven- 
tion on the receive side of an ATM network. 

Rgures 10 through 13 are schematic represents- 



tions of various combinations 
appicable to the invention. 
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Detailed Description of a Preferred Embodiment of the 
Invention 5 

Figure 1 is a block diagram representing an ATM 
network with attachment to conventional equipments 
made to vehiculate and process voice information of 
either GSM nature or originating in fixed stations. One w 
should already understand that the limitation to voice is 
just given for illustration purposes and to simplify the 
description of the preferred embodiment of this inven- 
tion. It should by no means be considered as limiting the 
invention which applies equally, for instance, to multime- is 
dia including also voice or image data. 

The network of Figure 1 is represented as including 
three intermediate nodes labelled Node 1 , Node 2 and 
Node 3, and at the edge of the network, two access 
nodes labelled Node A and Node B. These nodes are 20 
interconnected by lines or trunks labelled TK1, TK2. 
TK3, ...etc , in figure 1. 

A PBX(A) is attached to Access Node A while a 
PBX(B) is attached to Access Node B. Said PBXs serve 
n telephone sets each, which sets are labelled TA1. 25 

TA2 TAn and TB1 , TB2 TBn respectively. 

Voice Servers functions are provided within Nodes 
A and B respectively to enable compressing voice data 
and lead to efficient bandwidth exploitation within the 
network. 30 

Also represented is a GSM Base Station connected 
to Node A, said Base Station is serving mobile stations 
MS1, MS2... and thus enabling the transportation of 
GSM compressed data over the ATM network as 
needed. 35 

As shown in Figure 1. the PBXs and GSM Base 
Station could be attached to the ATM network through 
Packet Switching Access Nodes or be attached directly 
(see dashed lines in figure 1). As already mentionned, 
the data flowing within the ATM network, both through 40 
the network nodes and trunks may derive from image or 
video origin as well, which have not been represented in 
figure 1 for symplifying the drawings. 

As mentioned, in the ATM network, the data are 
conventionally arranged into so called ATM cells, each 45 
including a 48 bytes long payload with a 5 bytes long 
header. An ATM cell is therefore of a predefined fixed 
length. But the data provided to the network ports, say 
access Node A may be, and often are. in the form of var- 
iable length often shorter than the conventional ATM cell so 
payload. Said variable length packets may have to fol- 
low several paths. For instance, the ATM network is 
organized to include several Virtual Channels (VC) over 
a given Virtual Path (VP) along the network trunks. Data 
from different users, each defined by a specific Channel ss 
Identification (CID) may be fed to the same Virtual 
Channel and therefore may be aggregated through a 
multiplexing operation. But one may also block multiple 
variable length compressed voice packets from same 
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user. This may den ^J^> the generation of a, say 400 
bytes long message, concatenating short variable 
length user packets. . Not only each user's packet may 
be shorter than 48 bytes, but it could be of variable 
length. The problem faced here addresses efficient 
encapsulation and transport of these short user packets 
inside an ATM cell stream. Efficiency requires not only 
avoiding the padding of ATM cells with dummy data but 
also avoiding the requirements of modifying the already 
existing network hardware. 

This invention reaches both goals by providing a 
method for organizing user data aggregation or con- 
catenation and processing, for fitting perfectly with the 
International Telecommunications Union Standards as 
applied in the currently operating ATM networks and 
more particularly fitting with the ATM Adaptation Layer 
type 5 (AAL5). 

The structure of said AAL type 5 is represented in 
figure 2. This figure defines the various sublayers 
between two Service Access Points (SAP). An original 
Convergence Sublayer (CS) has been divided into a 
Service Specific Convergence Sublayer (SSCS) and a 
Common Part Convergence Sublayer (CPCS). A third 
sublayer is defined for Segmentation and Reassembly 
(SAR). The various sublayers cooperate to provide the 
AAL type 5 services from top down on the sender side 
and from bottom to top on the receiver side. Sending 
shall imply segmentation while receiving implies reas- 
sembling data. 

In the transmit direction and with the presently 
available hardware, given a variable length payload, the 
AAL5 defined hardware shall provide a packet struc- 
tured as represented in figure 3. The CPCS Protocol 
Data Unit payload (CPCS-PDU) used to carry the CPS- 
SDU (or user data) is, as required, padded with a zero 
to 3 bytes long field followed by CPCS-PDU trailer. The 
CPCS-PDU trailer includes : 

- a first field with CPCS-User to User (CPCS-UU) 
indications. The CPCS-UU field is used to transpar- 
ently transfer CPCS User to User information. On 
presently operating implementations, the CPCS- 
UU is set to zero. In this invention, said CPCS-UU is 
made to include an SSCS-Trailer Offset (STO) field, 
defined to vehiculate information from the SSCS 
sublayer, and a Reserved (RES) field which can be 
used for other purposes. 

a Common Part Indicator (CP I) field, used for 
instance to align CPCS-PDU trailer to a predefined 
length. This field is also set to zero on the imple- 
mentations presently operating. 

a length field used to encode the length of the 
CPCS-PDU payload field. 

a CRC field to store a CRC-32 enabling checking 
for the validity of the data, is used to detect bit 
errors in the CPCS-PDU. The CRC field is filled with 



4 



the value of a CRC calcuj^Bwtiich is performed 
over the entire contents ofme CPCS-PDU, includ- 
ing the CPCS-PDU payload and me PAD field. 
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d^^fc codings shall help both saving 
Danl^th and improving the processing 



Figure 4 gives a schematic representation of the 
AAL and ATM layers operating according to this inven- 
tion. Let's assume there are n Connection End Points 
labelled CEP1, CEP2. .... CEPn entries to a Service 
Access Point (SAP). The Service Specific Convergence 
Sublayer operates to concatenate the corresponding 
variable length packets or Service Data Units labelled 
AAL SDU1 . AAL SDU2 AAL SDUn from the Connec- 
tion End Points, into an SSCS PDU Payload. While fig- 
ure 4 does not show it explicitely. in the preferred 
embodiment of this invention, this is performed by start- 
ing each new AAL SDU concatenation on a 4 bytes (i.e 
32 bits) boundary following the end of the previous AAL 
SDU concatenated. The concatenated AAL SDUs 
define the SSCS PDU (Protocol Data Unit) payload 
which is encapsulated or appended with an SSCS 
Trailer (or Subheader). 

In this invention, the SSCS Trailer Offset (STO) 
which is 4-bits long, shall be used to compute the offset 
to the beginning of the SSCS trailer. The value of this 
offset is defined as a multiple of four bytes and assumes 
that the SSCS trailer starts on a 32 bit (i.e 4 bytes) align- 
ment. In other words, the beginning of the SSCS trailer 
is located at the end of the CPCS-SDU justified on the 
next 32nd bit boundary. The STO field shall also be 
used to indicate that the data are processed in accord- 
ance with this invention. 

Various codes may be adopted for the STO field 
contents. For instance, one may def ine these codes as 
indicating : 

STO=0 for No trailer 

STO=1 indicating that the SSCS trailer is between 1 
and 4 bytes long, 

STO= 1 5 indicating that the SSCS trailer is between 
57 and 60 bytes long. 

The SSCS PDU payload appended with the sub- 
header define the CPCS PDU payload or CPCS-SDU 
as detailed in figure 5. The SSCS payloads are derived 
from the various AAL SDUs (i.e AAL SDU1. AAL SDU2. 

AAL SDUn) padded with a zero to three bytes long 

PAD to enable the above mentionned concatenation to 
start on a 32 bits boundary. Then, the SSCS Trailer (or 
so-called subheader) is made to sequentially establish 

the list of Channel Identifications (ODi) with i=1, 2 n. 

for the SSCS payloads. and specify the various User 
Data Lenghts (UDLi) with i=l,2...,n. As shown in figure 
5, the SSCS trailer is constructed by concatenating 
CID1, UDL1 ; CID2, UDL2; CIDn. UDLn. 

As an improvement, one may define a so-called 
Default Channel ID herein labelled (DC ID) and/or a 
default User Data Length which shall herein be labelled 



DUDL. These 
transmission ban? 
time. 

A protocol to change default values is defined in the 
5 CID 255. This protocol uses two messages, one being a 
Request to change default value and the other being an 
acknowledgement. During the time window between 
transmission of request to change and reception of a 
corresponding acknowledgement, the transmit side of 
io the network considers that it has no more default value. 
The explicit CID and UDL are then used in the SSCS 
Trailer and data transmission continues. The traffic may 
therefore remain uninterrupted in between. 

More particularly, the channel ID field shall not be 
is present under the following conditions: 

Default channel with a single AAL5 SDU. In this 
case, there is no SSCS Trailer. 



20 



Default channel with a non default User Data 
Length. In this case, there is a User Data Length 
field associated to the AAL5 SDU. 



One should note that there is always at least one 
25 control field per AAL5 SDU when multiple SDUs are 
blocked in a PDU. This enables identifying for which 
SDU each control field applies. 

As per the User Data Length (UDL) field, it shall not 
be present under the following conditions : 

30 

Single SSCS payload. In this case, the length field 
in the AAL5 CPCS Trailer identifies the length of the 
AAL SDU. 

35 . The User Data Length has a default value. 

In addition, each field is encoded with a so-called 
Basic Encoding Rule (BER). Accordingly, Channel IDs 
are coded in the range 130 to 255, with the CID=255 
do being used as the signalling channel to change the 
default values. In other words, this enables adapting the 
default values to the current operating conditions. 

The coding ranges, from zero to 129, are used for 
defining the User Data Length. 

45 

If the length of the User Data field is smaller or 
equal to 128. UDL is one byte long, and gives the 
length of the SSCS payload. 

so If the length of the User Data field is greater than 
128. the UDL is three bytes long and coded as fol- 
lows : 

byte 1 = 129 

55 bytes 2-3 = Length of the User Data field. 



The Basic Encoding Rules are also applied as fol- 



lows 
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If there is a single SSCS payll^P&sociated to the 

default channel, there is no SSCS trailer and 
STO=0. In this case, the Length field in the AAL5 
CPCS trailer identifies the length of the AAL SOU. 

If there is a single SSCS paytoad associated to a 
non default channel, or multiple SSCS payloads. 
the SSCS trailer contains at least one control field 
per SSCS payload. 

This enables identifying for which SOU each control 
field applies. 

For each SSCS payload : . 

If the channel has the default value, and the User 
Data Length has the default value, only CID is 
present. 
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If either the channel has a non default value, or the 
User Data Length has a non default value, only the 20 
field associated to the non default value is present. 

If both the channel has a non default value, and the 
User Data Length has a non default value, both 
fields are present and the CID field is set before the 25 
UDL field. As a consequence: 

When a CID is followed by a UDL. they both 
apply to the same SSCS payload. 

3C 

When a UDL is followed by a CID. the UDL is 
associated to the initial SSCS payload, and the 
CID is associated to the next SSCS payload. 

Turning back to figure 4, one may notice that the 35 
CPCS PDU payload having been appended with the 
CPCS PDU trailer (or second trailer) the process is then 
ready for segmentation by the conventional Segmenta- 
tion and Reassembly (SAR) layer of the AAL type 5. The 
SAR SDU. as provided by the CPCS layer, defines a 40 
global payload which is then segmented into 48-bytes 
long SAR PDU payloads each providing an ATM cell 
payload for the ATM layer. Each cell payload need then 
only be conventionally encapsulated with the 5-bytes 
long ATM header to provide an ATM cell. 45 

It should be however noted that for some applica- 
tions, said second trailer may just require the so-called 
STO indications, whereby the resulting global payload 
thus generated is ready for being forwarded over the 
network. 50 

Turnin back to ATM, we may note that each ATM 
cell shall contain one or several AAL SDUs or portions 
of these. The last ATM cell shall include the SSCS trailer 
followed by padding bits if required and the conventional 
AAL5 Trailer including the conventional CRC 32 for 55 
validity checking purposes. 

Accordingly, no modification is required to the cur- 
rently used hardware based on AAL5 applications and 
already available in conventional ATM networks. This 
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certainly means tha^^finvention provides a very con- 
venient method, enabling avoiding the hassle of redefin- 
ing standards and modifying existing hardware. A man 
skilled in. the art of digital networks shall indeed appre- 
ciate the advantages of this invention. 

In addition, the algorithm and therefore the corre- 
sponding software for implementing the method of this 
invention are fairly simple, as shall appear from figures 
6 and 7. 

As already mentioned, the user data (AAL 
SDU1....AAL SDUn) are concatenated in the SSCS 
PDU payload. This concatenation is fairly simple. But to 
further simplify the process, no matter how long an AAL 
SDUi might be, the next block (i.e AAL SDUi+1 ) shaJI be 
aligned on a multiple of 32 bits following the beginning 
of AAL SDUi concatenation. If required, padding bits 
shall be inserted at the end of AALSDUi. 

Now, represented in figure 6 (including figure 6A 
and 6B) is the flowchart for building up the SSCS Trailer 
(i.e see transmit side of the user-to-user communication 
process). 

Let's first note that for efficiency purposes, a prede- 
fined time limitation threshold is set for the concatena- 
tion operation. Accordingly, a timer is first set to zero 
and a packet count is first started (N=0). while a scan- 
ning index I is set to one. This is step 1 . Then the sys- 
tem gets the first AAL SDU and N is increased by one 
unit. The corresponding channel ID is checked versus 
the default channel ID (step 2). Should the test result be 
positive, then a subsequent test is performed (step 3). 
this new test is made to check whether the considered 
User Data length is equal to the default value selected 
for the considered channel. In case of positive answer to 
this test the considered SSCS Trailer byte (also called 
"octet") CO(l) to transmit is equal to the Channel Identi- 
fication and I is increased by one unit (step 4). The proc- 
ess waits then for the next AAL SDU (step 5). But 
should the answer to the test of step 3 be negative, then 
still anoyher test is performed to check whether the con- 
sidered User Data Length is smaller than the decimal 
value 129 (step 6). In case of positive answer to this 
test, theconsidered trailer byte to transmit (CO(l)) is 
made to provide the the value of the User Data Length 
(step 7) and I is increased by one unit. In case of nega- 
tive answer to the test performed at step 6. the trailer 
byte to transmit is made equal to 129 and is followed by 
to subsequent bytes (i.e. CO(l+l) and CO(l+2)) defining 
the User Data Length(steps 8 and 9). Accordingly, I is 
increased by three units. The process goes then to step 
5 waiting for the next incoming AAL SDU. 

Now, in case of negative answer to the test of step 
2. the byte CO(l) is coded according to the considered 
Channel Identification 5CID(N)) (step 10) and a new 
test is performed on the User Data Length versus the 
default fot the corresponding channel as identified (step 
1 1). should this test be positive. I is increased by one 
unit and the process goes again to step 5 waiting for the 
next AAL SDU to come. Otherwise another test is per- 
formed (step 12) to check whether the considered User 
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Data Length is than the decimal 29. If this is true, 

then the User Data Length is codec! with the next byte 
(step 13). I is increased by two units and the process 
goes to step 5. But should the result of test 12 be nega- 
tive, then the byte CO(l+1) is coded at 129 (step 14) and 
the next two bytes are used to code the considered User 
Data. Length (UDL(N)) (step 15). I is increased by four 
units and the process goes to step 5 waiting for the next 
AAL SDU to come. Before fetching the next AAL SDU 
the timer is always checked versus the above men- 
tioned time threshold. If the timer did not yet reach the 
predefined threshold then the process loops back to 
fetching the newt AAL SU and go through the whole 
above described trailer process. Otherwise, if the timer 
expired, then a new test is performed (see step 1 6 in fig- 
ure 7). If the count N=1 , then there should be no SSCS 
Trailerand the STO field is set to zero (step 17). But 
should the answer to test 16 be negative, then the 
SSCS Trailer is concatenated (step 18) ; the STO value 
is set to the length of the trailer divided by four and writ- 
ten in the CPCS-UU (steps 19 and 20). The trailer con- 
struction is then over. 

In addition to the above mentioned advantages of 
this invention, even the receive pan operation of the 
invention method not only fits perfectly to the existing 
standards and accordingly needs no special hardware 
modification, but in addition, its implementation should 
involve rather simple algorithms. 

The standard functional model for the receiver side 
of the AAL type 5 is schematically represented in figure 
8. Again, no modification is required to reassembling 
layers operations including SAR and CPCS operations. 
Therefore, the received ATM cells payioads are con- 
catenated into a CPCS SDU and forwarded to the 
SSCS layer as an SSCS PDU payload with an SSCS 
PDU Trailer or subheader if the STO field content is not 
null. The remaining process shall then be performed at 
the SSCS layer level to reconstruct and identify the var- 
ious AAL SDUs to be forwarded to users or eventually to 
another network. 

The SSCS layer operations may be performed 
according to the flowchart of figure 9 bearing in mind 
that all payioads have been concatenated at the begin- 
ning of the considered frame, with channel IDs and Unit 
Data Lengths being defined in the SSCS trailer. Accord- 
ingly the algorithm should focus on processing the 
SSCS Trailer attached to the SSCS PDU payload even- 
tually padded, scanning this trailer byte by byte. 

The process starts with setting the counter N indi- 
cating the number of concatenated AAL SDUs to one 
and then checking whether the STO field content is null. 
If this is the case, then the Channel ID looked for is 
equal to the default Channel ID and the User Data 
Length is equal to the CPCS PDU length. The process 
then is completed. 

Otherwise, should the STO field content be different 
from zero, then the SSCS trailer field is located in the 
received frame at the SSCS layer operating level and its 
content is scanned byte by byte, herein designated as 
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the Control Octet H^), with i=1. 2. 3 k being the 

current position within the scanned SSCS Trailer, and k 
defining the length of the SSCS Trailer derived from the 
content of the STO field. 
5 The process starts with setting i=1 and reading the 

Control Octet pointed at (step 1). Should CO(i) not exist 
i.e. i smaller or equal to k . then the process ends. But if 
CO(i) exists, its content value is tested versus a value 
coded to be the binary value 129 (step 2). If CO(i) is 
10 smaller than or equal to 129. then the current CID (i.e. 
CID(N) is equal to the default value selected for a Chan- 
nel Identification (i.e. DCID) (step 3). A test is then per- 
formed to check whether CO(i) is equal to 129 (step 4). 
If this is the case, then as mentioned above, one knows 
is that the current User Data Length is coded with the two 
next bytes CO(i+1) and CO(i+2) which are read and 
stored, the pointer index i is increased by three units 
(step 5); N is increased by one unit and the process 
loops, back to step 1 for reading, a new Control Octet. 
20 Otherwise, should CO(i) considered at step 4 be differ- 
ent from 129. then the currently read byte (CO(i)) indi- 
cates the value for the User Data Length, which is 
stored and i is increased by one unit (step 6) before 
increasing N by one and looping back to step 1 . 
25 But should the result of the test performed at step 2 
be negative, then the process checks whether CO(i+1) 
exists, i.e. whether i+1 is smaller or equal to k, (step 7). 
If not then the scanning of the SSCS Trailer ends after 
setting the Channel Identification equal to the consid- 
3C ered byte CO(l) value and the value of the User Data 
Length equal to the default User Data Length selected 
for the considered Channel ID (step 8): Otherwise, 
CO(i+1 ) is read and checked versus the value 129 (step 
9). If CO(i+1) is higher than 129. the byte CO(i) provides 
35 the CID(N) and the current User Data Length,is set to 
the predefined default value for the considered. channel 
(step 10). Then i and N are both increased by one unit 
and the process loops back to step 1 for fetching the 
next CO(i). 

4G But should the answer to the test performed at step 
9 be positive, then the current CO(i) defines the value of 
the Channel Identification (step 11). 

A new test (step 1 2) is. performed to check whether 
CO(i+l ) is equal to 1 29. If this is the case, then the User 

45 Data Length is represented by the two next consecutive 
bytes. CO(i+1) and CO(i+2) within the SSCS Trailer 
(step 13); i is increased by four units. N is increased by 
one unit and the process loops back to step 1. On the 
contrary, should the result of the test performed at step 

so 12 be negative, CO(i+i) provides the value of the User 
Data Length (UDL(N)) (step 14). Then i is increased by 
two units, N is increased by one unit and the system 
loops back to step 1 . 

As already mentioned the invention applies to vari- 

55 ous combinations of users, i.e. by performing so-called 
"blocking" function or so-called "multiplexing" function. 
Through the blocking function one concatenates several 
AAL SDU from one user in one AAL PDU ; while by the 
multiplexing function, one multiplexes several data 
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streams from different AAL userJ^^ne ATM connec- 
tion. Each data stream is then identified by a specific 
Connection End Point (CEP). 

Figures 10 through 13 show the four possible com- 
binations associated to blocking and multiplexing tunc- s 
tions. 

When a single AAL SOU from a unique CEP is 
transported in a single AAL PDU, then neither blocking 
nor multiplexing functions are obviously performed. 
CEP1 can then either be the only CEP of the SAP or be 10 
the default of the SAP. 3. 

When a blocking function is performed, then multi- 
ple AAL SDUs from a single CEP are transported in a 
single AAL PDU. CEP1 can either be the CEP of the 
SAP or be the default CEP of the SAP. A UDL field is is 
needed to identify the length of each user data block or 
packet. 

When a multiplexing function is performed, multiple 
AAL SDUs from different CEPs are transported in multi- 
ple AAL PDUs. A CID field is needed to identify the 20 
Channel ID associated to each CEP. 

When both multiplexing and blocking functions are 
performed, multiple AAL SDUs from different CEPs are 
transported in a single AAL PDU. A CID field and a UDL 
field are both needed to identify the Channel ID associ- 2s 
ated to each CEP and the User Data Length for each 
user data block. The Basic Encoding Rule for the SSCS 
Trailer and STO field defines for each AAL PDU which 
function (blocking, multiplexing or both blocking and 
multiplexing, or none of these) is performed. 30 

In other words, this method is very flexible and does 
not require any negociation between the two peer AAls 
to specify which function is used. 

It should obviously be understood that different 
basic coding rules, and numerical parameters could be 35 
selected and the invention be applied to one or several 
media without departing from the scope of this inven- 
tion. 
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A data processing method for efficiently transport- 
ing multimedia data packets over a digital packet 
switching network, said method including, on the 
transmit side, concatenating fixed and/or variable 
length data packet payloads, issued from one or 
several users, and appending said concatenated 
data payloads with a subheader or trailer which 
trailer concatenates User Channel Identifications 
(ClDs) and User Data Length(s) (UDLs) values of 
the respective concatenated data payloads, at least 
a trailer length identifyer being appended therewith, 
whereby a global payload is being defined, which 
global payload shall then be forwarded for transpor- 
tation over the said packet switching network. 

A data processing method for efficiently receivig 
multimedia data packets of fixed, and/or variable 
length sent according to the transmit method of 
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50 



55 



claim 1 over sl^^bcket switching network, said 
method including reassembling the reveived net- 
work payloads and then splitting the reassembled 
payload into the originally transmitted fixed or varia- 
ble length payloads based on the information pro- 
vided within the received appended trailer 
concatenating the User Channel Identifications 
(CIDs) and User Data Lehgth(s) (UDLs) values of 
the respective concatenated data packets. 

A data processing method according to claim 1 . for 
efficiently transporting multimedia data packets of 
fixed and/or variable length over an ATM network 
made to vehiculate fixed length Asynchronous 
Transfer Mode (ATM) cells including a fixed length 
ATM cell payload field and a fixed length cell header 
field, said method including, on the transmit side: 

concatenating said multimedia data packets 
issued from one or several users into a so- 
called Service Specific Convergence Sublayer 
(SSCS) Protocol Data Unit (PDU) payload as 
defined by the International Telecommunica- 
tion Union (ITU)for the ATM Adaptation Layer 
type 5; 

appending to said SSCS PDU payload a so- 
called trailer, which trailer concatenates User 
Channel Identification(s) (CIDs) and User Data 
Length(s) (UDLs) of the respective concate- 
nated data packets, thereby generating a so- 
called Common Part Convergence Sublayer 
(CPCS) Service Data Unit (SDU) or CPCS 
PDU payload; 

providing said CPCS PDU payload with a con- 
ventional CPCS Protocol Data Unit (PDU) 
trailer as defined by the International Telecom- 
munication Union (ITU) standards, whereby a 
conventional ITU Segmentation And Reassem- 
bly (SAR) layer Service Data Unit (SDU) is 
being generated; 

segmenting said SAR SDU into segments each 
having the length of a conventional ATM cell 
payload. and generating and attaching to each 
said segments, a conventional ATM header 
whereby conventional ATM cells are being gen- 
erated for being forwarded over the said ATM 
network. 

A data processing method for efficiently receiving 
multimedia data packets of fixed and/or variable 
length transmitted over an ATM network according 
to the method of claim 3. said receiving method 
including: 

receiving said ATM cells and removing the ATM 
header to derive ATM cell payloads therefrom; 
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concatenating said re^^^J ATM ceils pay- 
loads thereby recovering the original CPCS 
PDU payload with attached CPCS PDU Trailer; 



11. 
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locating, within said CPCS PDU payload, the 5 
transmitted trailer including the original User 
Data Lengths (UDLs) and Channel IDs (CIDs) 12. 
attached to the so-called SSCS PDU payload; 



A method fd^pbiently receiving data packets 
transmitted over an ATM network according to claim 
10, wherein the coded value within said Service 
Trailer Offset field is monitored to control the receiv- 
ing operations. 



scanning said trailer to decode said UDLs and 
CIDs and recovering the original data packets 
from within the SSCS PDU payload accord- 
ingly. 

A data processing method according to claims 3 or 
4 for efficiently transporting multimedia data pack- 
ets of fixed or variable length over said ATM net- 
work, wherein said users are connected to the ATM 
network either directly or through so-called Packet 
Switching Access Nodes. 

A data processing method for efficiently transport- 
ing data packets according to anyone of claims 1 
through 5. wherein said original data packets 
include packets of a length smaller than the con- 
ventional ATM cell payload length. 
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A data processing method for efficiently transport- 
ing data packets of fixed and/or variable length 
according to claims 6 or 7, wherein default values 
have been defined for said Channel IDs and/or 
User Data Lengths. 

A data processing method according to claim 8 
wherein said default values are made modifiable 
upon user's request and acknowledgement by the 
receive party with no traffic interruption in-between, 
the process using then to explicit values. 
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20 



25 



A data processing method for efficiently transport- 
ing data packets of fixed or variable length as 
claimed in claims 5 or 6, wherein said concatena- 30 
tions and appending made for generating said 
CPCS Service Data Unit (SDU) payload are each 
started on a limit of a multiple of a predefined 
number of bytes with respect to the beginning of 
said payload. with padding bytes being inserted in 
between concatenated data packets and/or trailer if 
required. 



35 



40 



45 



50 



10. A data processing method for efficiently transmit- 
ting data packets over an ATM data network 
wherein the so-called Service Trailer Offset (STO) 
field within the CPCS PDU trailer field is used to 
indicate the transmission of data packets made 55 
according to any one of claims 3 through 8; 
whereby specifying the existence of a trailer and its 
length. 



A method for efficiently transmitting or receiving 
data packets according to anyone of claims 3 
through 11, wherein coding fields for said User 
Data Lengths (UDLs) and Channel IDs (CIDs) are 
predefined for being exclusive with each other 
according to a so-called Basic Encoding Rule. 

A method for efficiently transmitting and receiving 
multimedia data packets according to claim 12 
wherein said CPCS-PDU trailer is made to include 
a predefined code specifying whether the transmis- 
sion is operating in a multiplexing mode, in a block- 
ing mode, in both modes, or in neither one. 
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